Traditionally, Unix devices can be used in two different `modes', either by reading/writing to the device file, or by issuing controlling commands to the device, by the device's ioctl () call. The problem with CDROM drives, is that they can be used for two entirely different purposes. One is to mount removable file systems, CDROMs, the other is to play audio CD's. Audio commands are implemented entirely through ioctls, presumably because the first implementation (SUN?) has been such. In principle there is nothing wrong with this, but a good control of the `CD player' demands that the device can always be opened in order to give the ioctl commands, regardless of the state the drive is in.
On the other hand, when used as a removable-media disc drive (what the original purpose of CDROMs is) we would like to make sure that the disc drive is ready for operation upon opening the device. In the old scheme, some CDROM drivers don't do any integrity checking, resulting in a number of i/o errors reported by the VFS to the kernel when an attempt for mounting a CDROM on an empty drive occurs. This is not a particularly elegant way to find out that there is no CDROM inserted; it more-or-less looks like the old IBM-PC trying to read an empty floppy drive for a couple of seconds, after which the system complains it can't read from it. Nowadays we can sense the existence of a removable medium in a drive, and we believe we should exploit that fact. An integrity check on opening of the device, that verifies the availability of a CDROM and its correct type (data), would be desirable.
These two ways of using a CDROM drive, principally for data and secondarily for playing audio discs, have different demands for the behavior of the open() call. Audio use simply wants to open the device in order to get a file handle which is needed for issuing ioctl commands, while data use wants to open for correct and reliable data transfer. The only way user programs can indicate what their purpose of opening the device is, is through the flags parameter (see open(2)). For CDROM devices, these flags aren't implemented (some drivers implement checking for write-related flags, but this is not strictly necessary if the device file has correct permission flags). Most option flags simply don't make sense to CDROM devices: OCREAT, ONOCTTY, OTRUNC, OAPPEND, and OSYNC have no meaning to a CDROM.
We therefore propose to use the flag ONONBLOCK to indicate that the device is opened just for issuing ioctl commands. Strictly, the meaning of ONONBLOCK is that opening and subsequent calls to the device don't cause the calling process to wait. We could interpret this as ``don't wait until someone has inserted some valid data-CDROM.'' Thus, our proposal of the implementation for the open() call for CDROMs is: